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Foreword 

Hiis Technical Report has been produced by the 3'' Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following 
formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG 
with an identifying change of release date and an increase in version number as follows: 

Version x.y.z 
where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; - ......... ... 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document discusses architectural issues and describes functionalities required for the Multimedia 
BroadcastMiuIticast Service. MBMS requirements are discussed in [2] and it is the intention of this document to 
present one or more alternatives to achieving the required functionality within 3GPP networks. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. ^ 

• Referc^nces are either specific (identified by date of publication, edition number, version number etc ) 
or non-specific. ' 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document 
(including a GSM document), a non-specific reference implicitly refers to the latest version of that 
document in the same Release as the present document. 

[I] 3GPP TR 21.905; "3G Vocabulary". 

[2] 3GPP TS 22. 1 46: "Multimedia Broadcast/Multicast Service; Stage I ". 
f3 1 IETF RFC 27 1 0 n 999): ••M.illir.nii t Listener ni.^rnyerv rMT fnr Tpwft" 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in [1 ] and the following apply. 

MBMS broadcast activation: The process which enables the data reception from a specific broadcast mode MBMS 
On a uE. 

MBMS multicast activation: The process which enables a UE to receive data from a specific MBMS multicast 
Thereby the user joms a specific multicast group. The activation may be performed by the user and it may be 
performed inherently for subscribed multicast services. 

MBMS Notification: The mechanism which informs the UEs about a forthcoming (and potentially an ongoina) data 
transfer from a specific MBMS service — — 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations appJy: 
IGMP Internet Group Management Protocol 

MLD Multicast Listener Proiocol Discovcry I 
MBMS Multimedia Broadcast/Multicast Service ' 

Other abbreviations used in the present document are listed in 3GPP TR 21.905 [1]. 
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4 Introduction 



The MBMS [2] is a point-to-multipoint service in which data is transmitted from a single source entity to multiple 
users. Transmitting the same data to multiple users allows network resources to be shared. 



The MBMS offers two modes: 

• Broadcast Mode 

• Multicast Mode 



5 High Level Functionality 

A short overview ' 

5.1 Architecture Principles 

In developing and evaluating different architectural options for MBMS. the following principles should be taken as 
general architectural guidelines that should be followed: 

1 . MBMS architecture shall enable the efficient usage of radio-network and core-network resources with the 
main focus on the radio interface efficiency. Specifically, multiple users should be able to share common 
resources when receiving identical traffic. 

2. The MBMS architecture shall support common features for MBMS multicast and broadcast modes e e 
both modes shall preferably use the same low-layer bearer for data transport over the radio interface. 

3. MBMS architecture shall support external data sources in both modes. MBMS shall support both IP 
multicast and IP unicast .sources. 

4. MBMS architecture should re-use. to the extent possible, existing 3GPP network components and protocol 
elements thus mmimizing necessary changes to existing infralstructure and providing a solution based on 

well-known concepts. r e w o^u 

5. MBMS shall be a poini-to-multipoint bearer .service for IP packets in the PS domain. 

6. MBMS shall be interoperable with IETF IP Multicast. 
MBMS shall support IETF IP Multicast addressing. 

^TJJ' ^^rrTr^Z't """^ " -^"' J "•'"''y MBMS sh^ll be backwards compatible with the already 
specified IETF IP Multicast support in GGSN. 

8. It shall be possible Ibr UEs to receive MBMS when the terminal is attached. 



7 



9. It shall be possible for UEs to receive MBMS data in parallel to other services and ^rii;ntrfti« *si»nallin. r 
(e.g. paging, voice call). ^ * 

10. MBMS shall support differcnt quality of service levels. The mechanisms for this are for further study one 
example is repetitions to all u.sers. ^luuy, unc 

1 ] . MBMS service areas shall be defined per individual service with a per cell granularity. 

12. MBMS is not supported in the CS domain. 

13. When the UE is already receiving MBMS, it shall be possible for UE to be notified about other MBMS 
services. 
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14. Charging data shall be provided per subscriber for MBMS multicast mode . 

15. The MBMS bearer service concept should contain the decision making process for selection of point-to- 
point or point-to-multipoint configurations. 

16. The architecture should be able to provide home MBMS multicast services to users when roaming outside 
their home network as subject to interoperator agreements.- 

17. MBMS should be designed to minimise power consumption within the mobile station. 

18. -ffh — Applications shall be tolerant to packet loss and duplicadon e ge.g. due to UE mobility or transmission loss. 

19- "Tiie backwards compatibility of the MBMS ser vice to the R99 IP multicast delivery m echanism Qhall 
considered. Interworking possibilities between MBMS capable network elements and non-MBMS capable 
network elements (e.g. interworking wit h R99 IP Multicast service GGSNs^ shall be descriht^d 

5.2 Architectural Overview 

5.3 MBMS Reference Points 

Description of MBMS interaction with other endties within the network (e.g. User, VASP, Charging DB, Other?) 

5.4 High Level Functions 

Multimedia Broadcast/Multicast Service is associated with several logical functions that should be provided by the 
network. 

5.4.1 Authentication and Authorization 

5.4.1.1 Content provider Authentication and Authorization 

• MBMS should be able to identify and authenticate the content provider prior to receiving control or 
data from it. 

• A content provider may request to provide a multicast or broadcast service using MBMS possibly 
stating desired QoS, geographical areas and other service-related parameters. MBMS shall be able to 
authorize this service provision with the requested parameters prior to service initiation. 

5.4.2 Efficient Routing and Resource Usage 

• The MBMS shall be able to efficiently route multicast and broadcast over the radio interface and 

within the radio network. Efficient routing within the core-network is desired as well. — 

• In Multicast mode, MBMS should support multicast resource allocation where-by data transmission to a 
multicast group is carried out in certain cell only if multicast group members are to be found in that cell. 

5.4.3 Mobility Management and Service Continuity 

• MBMS shall support service continuity when moving from cell to cell within the multicast/broadcast 
area. 

NOTE: Loss of data may occur during this process. 

• MBMS should enable roaming users to receive both home and local multicast services. Roaming users should 
be able to receive local broadcast services as well. 
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5.4.4 Service Initiation and Termination 

• The UE shall be able to enable and disable broadcast service reception. 

• The UE shall be able to join and leave multicasl groups. Roaming users should be able to join and leave 
multicast groups in the home or visited net\york. 

• The MBMS must be able to authorize subscribers to join multicast groups (i.e. receive multicast services). 

5.4.8 Charging 

5.4.9 Security 

• To prevent unauthorized reception of multicast data, multicast transmission may be secured. 

^ • Jo .preyfcnt injectijDn of malicious content jnto the network MBMS shoujd be aWe to, authenticate the source 
and verify integrity of the data received from the content provider. 

5.4.10 Addressing 

5.4.11 Roaming 

6 Network and Protocol Architecture 

Options for different network architectures together with a rough description of necessary functionality and 
alterations required for network elements and protocols. 

6.1 MBMS Architecture 
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Fig. 1 MBMS Architecture 

In the MBMS architecture the SGSN performs user individual service control functions and the SGSN concentrates 
all individual users of the same MBMS service into a single MBMS service. The SGSN maintains a single connection 
with the source of the MBMS data. The SGSN duplicates the packets received from the GGSN for forwarding to each 
RNC involved in provision of a specific MBMS service. 
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The GGSN terminates the MBMS GTP tunnels from the SGSN and links these tunnels via IP multicast with the 
MBMS data source. The GGSN duplicates the packets received from the MBMS data source for forwarding to each 
SGSN to which a GTP tunnel is established for a specific MBMS service. 

The M-BBM-SC is an MBMS data source. MBMS data may he scheduled in the MBBM-SC, e.g. for transmission to 
the user every hour. It offers interfaces over that content provider can request data delivery to users. The MB-S GBM- 
SQ may authorise and charge content provider. 

The Cell Broadcast Cenle i C enlrQ (CBC) may be used to announce MBMS services to the users. How this is 
accomplished is FFS. 

The architecture allows for other MBMS broadcastymulticast data sources. Internal tkft^ata sources may directly 
provide their data. Data delivery by external sources is controlled by Border Gateways (BG) which may allow for 
example data from single addresses and ports to pass into the PLMN for delivery by an MBMS service. 

The architecture assumes the use of IP multicast at the reference point Gi. The MBMS data source has only one 
connection to the IP backbone. The reference point from the content provider to the MB -S G BM-SC is not 
standardised. It might become to complex or to restricti vc for se;rvice creation. For example, this may be a reference 
point between the MB-S eBM-SC and an authoring system, or the authoring functionality may be distributed between 
both entities. 

The same architecture provides MBMS broadcast services mainly by using the transport functions. The user 
individual SGSN functions are not required. Instead each individual broadcast service is configured in the SGSN. 

Note: For the terminal split case, MBMS shall be able to interoperate with an IP multicast client software on the TE 
The mechanism for this interoperability is FFS. 

6.1.1 SGSN Functions 

A number of functions provided by the SGSN for ptp bearer services may be used to provide MBMS: 

• The SGSN authenticates users based on subscription data from HLR 

• The SGSN authorises the usage of services/resources based on subscription data from HLR 

• The SGSN provides user individual service control ditjiPtP services) I 

• The SGSN provides user individual mobility management 

• The SGSN may limit the service area per individual user 

• The SGSN stores contexts per activated service per individual user 

• The SGSN generates charging data per service for each user 

• The SGSN provides CAMEL functions (e.g. prepaid) 

• The SGSN establishes RABs on demand when data hasve to be transferred to the-users j 

All these functions may be used in an MBMS architecture (potentially with modifications) for user individual control 
of MBMS multicast services, i.e. to activate, deactivate, authorise, ... the MBMS services For individual users. The 
mechanisms for provision of RABs on demand when data is to transfer may need extensions to provide shared 
resources for MBMS. 

6.1.2 GGSN functions 

The functions a GGSN could provide for MBMS are: 

• Message Screening 

• Charging Data Collection 
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• Mobility management 

• Tunnelling of data 

• Service (QoS) negotiation 

• Policing 

Message screening is not needed if the MBMS sources are internal in the PLMN or it is provided by the MB-S €BM- 
SC or the BG which are gateways to external MBMS data sources. 

Charging data may be collected for the MBMS data sources. But, the potential existing sources like ESS or MMS 
I provide charging information and very likely also the MB - SC BM-SC . User individual charging information is 
collected by the SGSN. It is not favourable to keep user individual contexts per multicast service in the SGSN and in 
the GGSN in parallel under the assumption that such user Individual contexts are stored as long as the user is 
attached. 

The rnobility management of the GGSN can not support MBMS as the GTP tunnels would be fixed. These tunnels are 
used by multiple UEs in parallel an can not move with UEs. ' ^ 

The tunnelling seems the most important GGSN function for MBMS. It allows the provision of HPLMN MBMS 
multicast services to users roaming in a VPLMN. The tunnelling separates the traffic of the different MBMS services 
from each other and allows therefore the use of the same addresses in HPLMN and VPLMN. A co-ordination of 

addresses between different PLMNs is not needed. 

A GGSN could simplify O&M when used to provide the parameters for the individual MBMS services at the service 
negotiation when the GTP tunnels are established. This approach has limitation when different configurations are 
required for the same service (potentially one SGSN has to provide different MBMS data for the same service in 
different areas, e.g. regional news). Then it has to be configured differently on the SGSN. Also the broadcast service 
needs to be configured on the SGSN, as there is no signalling with UEs which could trigger a tunnel establishment 
between SGSN and GGSN. 

The GGSN could police the traffic of the individual MBMS services. But, most MBMS data sources are allocated 
within the PLMN and therefore under control of the operator. In addition, the QoS profile is very likely configured on 
the SGSN, And, the RAB will limit the possible throughput to the maximum bitrate and inherently police the traffic. 

Most of the GGSN functions described above do not add any functionality useful for MBMS. Only for provision of 
HPLMN MBMS services to roaming users a GGSN is added to the architecture. The same approach is used for 
provision of MBMS services within one PLMN to avoid two different architectures. 

6.1.3 UTRAN Functionality 

6.1.3.1 Broadcast Mode 

6.1.3.2 Multicast Mode 



The UTRAN shall provide the following functionality for efficient support of MBMS 

• responsible for establishment of point to multipoint or point to point channels on the air interface to 
support MBMS. 

• capable of routing MBMS traffic over either a point to multipoint channel or over a point to point 
channel. 

• capable of discovering the number of MBMS users within a cell 

• makes the decision to select channel type (point to multipoint or point to point) based on the number of 
users within a cell receiving MBMS service. The threshold value for this is operator defined 
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6. 1 .4 Other MBMS functions 

Besides the user individual service control functions comparable to the functions already provided by an SGSN or 
GGSN there are some additional functions required for MBMS, mainly the specific data transport. It is assumed, that 
the SGSN performs the user individual service control, generates the charging data per user and establishes the RABs 
v^hen MBMS data is to transfer. The SGSN concentrates all user individual services into one MBMS service for each 
specific MBMS service. This includes the establishment of a number of RABs to transfer MBMS data to the radio 
network entities of the related service area and it includes a single connection between the SGSN and the GGSN for 
each individual MBMS service. The SGSN duplicates the data received from the GGSN for each RAB established lor 
the service. Similarly, the GGSN duplicates data received from the MBMS source for each GTP tunnel related to the 
same MBMS service. 

6.1 .5 MBMS Context 

The entities of the PLMN that provide MBMS services maintain one or more MBMS contexts for each active MBMS 
service An MBMS context contains information and parameters necessary for each MBMS service. An MBMS 
context contains among others the PDP address, which is the IP address of the.MBMS ser.vice.(IP Multicast address);-- 
and the APN used to access the MBMS service. The combination of the PDP address and the APN uniquely identify 
fhP MRMS servirft Other cont.>nt nf the MRM.S nnnie.xt i s ti is FFS whether PLMN entities maintain {Service 
specific MBMS context.s per UE. per network entitv. or both. 



6.1 .6 SM-SC functions 

The Mfi-SefiM::S£ is an MBMS data source. MBMS data may be scheduled in the MD-?>CBM-SC , e.g. for 
transmission to the user every hour. It offers interfaces to content providers who can request data delivery to users. 
-The Mft^.q PBM-SC may authorise and charge content provider. It may offer authoring tools for content creation. It is 
FFS whether the MrH^eEMzSC relays traffic from other MBMS sources, so that the }*ffi-S€BM::SC is the only 
source of MBMS data. The SM-SC may integrate the MBMS specific GGSN functions. Then, the GTP tunnel from 
the SGSN terminate at the MB-SGEMrSC- 

6.1.7 CBC functions 

The Cell Broadcast e««teCcntrc (CBC) may be used to announce MBMS services to the users. The functions a 
CBC could provide for MBMS service announcement arc FFS. 

6.2 <Architecture Option 2 Label> 



7 Functions and Procedures 



7.1 MBMS Data Transfer in the Core Network 

Multicast data must be available at the RNCs to be sent over the radio. The options for the data path are to send 
multicast data from a multicast ".source" (could be a multicast server or multicast capable node) to: 

• all RNCs; 

• only to selected RNCs which have multicast users, 

• 10 the all SGSNs to be further distributed by the SGSN to the RNCs, or 

• to selected SGSNs which have multicast users to be further distributed by the SGSN to the 
RNCs, or 



BNSDOCID- <XP 2231 a06A I > 



Release 5 Release 5 



SGPFSTO 23.846 Q.3 0 (2002-01 ) 3CPP Tn 9^ n ^i^ 3 p ( 20Q2 Q |) 

• to selected GGSN which support multicast service (possibly idcnlilied using APNs) and to be 
further distributed from the GGSN towards the RNCs. 

The first option is wasteful of network resources and also makes it difficult to send data to VPLMNs for roaming 
users. The second option, an optimisation of the first one, is to send data only to RNCs with multicast users within the 
PLMN under control of the activation centre but this cannot support roaming users cither. Handling user mobility is 
also an issue here if for example the UE is in PMM idle. 

Sending data to the GGSN in the last option is a good choice to support roaming users. The data is then multicast to 
the SGSNs with registered multicast users. Sending data through the SGSN - either directly (the third option) or via 
the GGSN (the last option) - has advantages since the SGSN is aware of the user location information even in PMM 
idle state but the use of lu-Hex introduces complexities. 

A combination of the above listed options can also be used - with direct transfer to RNC for the home users and via 
the GGSN to the roaming user. • 

Tlie protocol to use to send data to the RNC or SGSN (if they are the recipient NE as per options discussed above) 
could be GTP or usmg IP multicast. Using IP multicast would be more efficient over the transport network if it 
supports multicast routers 

Where the option to optimise and send data only to selected NEs is chosen, a signalling mechanism must be used to 
identify the appropriate nodes to set up the data path. If the data path is through the SGSN and GGSN sianallins 
similar to the existing GTP-C can be used to set up the tunnels. If IP multicast is used, the NEs wantin- to receive 
multicast data, such as RNC or GGSN that have multicast users, could indicate its inclusion using IGMP/MLD. 

The selection of an option is FFS. 

7.1.1 Intra Domain Connection of RAN Nodes to Multiple CN Nodes (lu-Flex) 

lu-nex brings some complications to the multicast architecture. lu-flex allows users on the same RNC to be 
registered in different SGSNs. Hence following the normal method of user plane using the same SGSN as the user is 
registered in could result in multiple streams to the RNC. 

Whenever a GTP tunnel has to be set up between the RNC and the CN for multicast bearers, (either due to relocation 
or service initiation), and lu Flex is configured in the network then the following options are available to reduce the 
impact on the network resource usage 

Options arc: 

• Use of a Default SGSN 

• Permitting multiple streams to RNC 

• Bypassing SGSN 

• RNC initia tes onlv required number oF RABx 

Option 1: Default SGSN 

1 . As a result of activation or relocation, the RNC has to decide whether a multicast stream has to be 
established for that user or whether he can be added to an existing stream (this is assuming the 
network is using a point to multipoint link), 

2. In order to ensure only one source of data to the RNC, the RNC has to have a known "default SGSN" 
which it uses to establish a pre-configured path lor the multicast stream. 

3. A control RAB will be established between the RNC and the SGSN the user is registered in, 

4. Volume based charging will he restricted. 

In this option, SGSN 1 is the "default SGSN". Only one RAB is established across the lu interface. 
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Option 2 "SGSN Bypass" 



This option would require GTP tunnel establishment and release for the user plane between the GGSN and RNC. 
without the SGSN being involved. Control plane information remains via the SGSN. Removing the SGSN from the 
data path would remove the inter-operator exposure available between SGSN and GGSN for roaming. Volume based 
charging would be restricted. 

SignalingSignailin§ 

Data path ^— 



SGSN 1 





Option 4 "RNC initiates, 



luired number of RABs" 



5. When thcd^^^^ffSTcr starts for an MBMS mullicasyJir^NC detects that mLTlti^tg-s^GSN sen3 
notifip^tf^f^to establish the same service. TheJWiCcstablishes the multicast RABvC^rthonly one 

L The other SGSNs establish no RABs for the MBMS multicast. But, the other SGS]vr>eceive the 
MBMS multicast data from the GGSN and generate volume charging information for the attached UEs. 

6. II lU-FIcx is employed, it is possible for users within a multicast group to be served by the same RNC 
but diil^rent SGSN. In this situation some of the MBMS IE must be the same even though different 
SGSNs may be involved. 
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It is FFS how this is done but the following solutions could be considered : 

a) These IE ean be assigned by the same network element 

b) A consistent rule is applied unlike the random generation as used in the TMSI 

c) Synchronization between different SGSNs. 




SGSN 1 



SGSNS 





GGSN 


SGSN 2 








7.2 Packet Temporary Mobile Group Identity in MBMS 

In order to avoid congestion of the paging channels (at least in GSM), one solution is to allocate one corMion ident 
to all members of each multicast group, which are served by the same SGSN. This Temporary Mobile Group Identity 
OMGI) could be allocated during a Routing Area Update, a GPRS Attach or a P-TMSI Reallocation procedure before 
the MBMS data transfer (e^ the first TMGI allocation might occur when the mobile joins the IP multicast group). 
Separate multicast groups have different TMGIs. TMGIs may also be used to notify users of broadcast transnussions. 
It is FFS whether the same TMGIs can be used in more than one SGSN. 

7.3 Decision process for selection of point-to-point or point-to- 

multipoint configuration 



7.3.1 Multicast Mode 

To ensure that radio resources are not wasted, the radio network needs to estimate the number of users in a cell in 
order to determine whether to establish a point to multipoint channel in that cell or point to pomt channels to each 
user. 

In the event of the number of users within a cell exceeding an operator defined threshold, the radio network will 
establish a point to multipoint channel in that cell. 

If a point to multipoint channel has been established and the number of users drops below an operator defined value 
then the radio network may be required to drop back to point to point channels. 

Note: The two thresholds may be different. 

It is FFS whether this change of channel can occur whilst data is being broadcast/multicast. 
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7.4 MBMS SGSN change procedure 



This procedure is performed when a UE in GMM IDLE changes the SGSN, i.e. there are no RABs and no signalling 
connections with the SGSN. The RABs for MBMS services are not exclusive for individual UEs. A signalling 
connection for an UE with MBMS services only is not intended as this is against the multicast concept. UEs which 
have only active MBMS services are therefore in GMM IDLE. These UEs perform the Routeing Area update with 
MBMS extensions as described below. The procedure is performed regardless whether MBMS data transfer is 
ongoing or not. The handling of potential ptj^PtP PDP contexts is not affected. The described procedure shows not all 
details of the Routeing Area update procedure. The MBMS specific additions to the Routeing Area update procedure 
are in bold. 



UE 



RAN 



1. Routeing Ar 



3. Security Fi motions 



new SGSN 



;a Update Rcqw :st 

2. SGSN Coj U c xt Request 

xt Response 



8. Routeing Asca Update Acccf 



9. Routeing Area Update Coi j^ 



old SGSN 



2^ SGSN Contc 

^ -S: ^ 



4. SGSN Coj Ttc xt Acknowledge 



5. Update Loca 



5^ Insert Subs c|iber Data 



5. Insert Subsci iber Data Ack 



GGSN I I HLR ~| 



tion 



5 ^ Cancel Lo ca 



5. Cancel Loca 



5 ^ Update Lo cajtion Ack 



6. Create MBlVfS Context Rt^est 



lete 



ion 



ion Ack 



7. Create MBN :S Context Conf rm 



Mobility between SGSNs 

L The UE moves from the service area of the old SGSN to the service area of the new SGSN. The UE 
sends a Routeing Area Update Request to the new SGSN. The RAN shall add an identity of the area 
where the message was received before.passing the message to the SGSN. 

2. The new SGSN sends SGSN Context Request to the old SGSN to get the MM, the PDP and the 
MBMS contexts for the UE. The old SGSN sends all UE contexts with the SGSN Context Response 
to the new SGSN. 

3. Security functions may be executed, e.g. authenticating the UE. 

4. The new SGSN sends an SGSN Context Acknowledge message to the old SGSN to indicate that is 
has taken over the control for that UE. 



6. 



All procedures to provide the subscription and security data in the new SGSN and to register the new 
SGSN at the HLR are performed. 

The new SGSN validates the UE's presence. If due to roaming restrictions the UE is not allowed to 
be attached in the SGSN, or if subscription checking fails, the new SGSN rejects the routeing area 



BNSDOCIDkXP 2231 206A I > 



Release SR e i e as e 5 3GPICTfl 23.846 0.3.0 (2002-01)5 



t81 6 0.3.0 (2002 - 01) 



update with an appropriate cause. If all checks are successful, the new SGSN constructs MM. PDP 
and MBMS contexts for the UE. The new SGSN checks each individual MBMS service indicated 
by the MBMS contexts of the UE. If it is the first UE with this specific MBMS multicast service 
on this SGSN the SGSN requests the creation of an MBMS context on the GGSN and the 
establishment of a GTP tunnel between the SGSN and the GGSN. 

7. The GGSN confirms the establishment of the MBMS context if performed according to step 6). 

8. The new SGSN responds to the UE with Routeing Area Update Accept. One or more TMGI may 
be allocated to the UE for MBMS» 

9. The UE acknowledges the new parameters by returning a Routeing Area Update Complete. 

7.5 MBMS relocation and handover 



This procedure is performed when a UE in GMM CONNECTED changes the SGSN, i.e. there is a signalling 
connections with the SGSN. The RABs of ptgPti^ services are transferred by relocation/handover. MBMS RABs are 
not exclusive for individual UEs. Active MBMS services of the UE are transferred to the new SGSN by the context 
transfer which is embedded in the relocation/handover procedures. The procedure is performed regardless whether 
MBMS data transfer is ongoing or not. The described procedure shows not all details of the relocation procedure 
Only the relocation procedure is described. The handover procedure has similar extensions for MBMS. The MBMS 
specific additions to the relocation procedure are in bold. 
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Figure 14: SRNS Relocation Procedure 

1) The source SRNC decides to perform/initiate SRNS relocaiion. 

2) The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, 
Source RNC to target RNC transparent container) to the old SGSN. The source SRNC shall set the Relocation 

TJ^PP. ''UE not involved". The Source SRNC to Target.RNC-Transparent Container includes the necessary 



^ - - ^ ^v.t-uiiiwA iiiv^iuvivxo ijii^ ut^^^c.: 

information for Relocation co-ordination, security functionality and RRC protocol context information 
(including MS Capabilities). 

3) The old SGSN determines from the Target ID if the SRNS Relocation is an inira-SGSN SRNS relocation or an 
inter-SGSN SRNS relocation. In case of inier-SGSN SRNS relocation, the old SGSN initiates the relocation 
resource allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint 
Identifier Signalling, MM Context, PDP Context, MBMS context, Target Identification, UTRAN transparent 
container, RANAP Cause) to the new SGSN. The Forward Relocation Request message is applicable only in 
the case of inter-SGSN SRNS relocation. 
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4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity. Cause, CN Domain 
Indicator, Source-RNC to target RNC transparent container, RABs to be setup) to the target RNC. Only the lu 
Bearers of the RABs are setup between the target RNC and the new-SGSN as the existing Radio Bearers will 
be reallocated between the MS and the target RNC when the target RNC takes the role of the serving RNC. 

5) When resources for the transmission of user data between the target RNC and the new SGSN have been 
allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response message 
(Cause, RANAP Cause, and RAB Setup Information) is sent from the new SGSN to old SGSN. This message 
indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e. the 
relocation resource allocation procedure is terminated successfully. The Forward Relocation Response 
message is applicable only in case of inter-SGSN SRNS relocation. 

6) The old SGSN continues the relocation of SRNS by sending a Relocation Command message (RABs to be 
released, and RABs subject to data forwarding) to the source SRNC. The old SGSN decides the RABs to be 
subject for data forwarding based on QoS, and those RABs shall be contained in RABs subject to data 

forwarding. 

7) The source SRNC may, according to the QoS profile, begin the . forwarding of data for the RABs to be subject - 
for data forwarding. 

8) Before sending the Relocation Commit the uplink and downlink data transfer in the source, SRNC shall be 
suspended for RABs, which require delivery order. The source RNC shall start the data-forwarding timer. 
When the source SRNC is ready, the source SRNC shall trigger the execution of relocation of SRNS by 
sending a RelocaUon Commit message (SRNS Contexts) to the target RNC over the lur interface. 

9) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution 
trigger Ts received. For SRNS relocation type "UE not involved", the relocation execution trigger is the 
reception of the Relocation Commit message from the lur interface. When the Relocation Detect message is 
sent, the target RNC shall start SRNC operation. 

1 0) The target SRNC sends a UTRAN Mobility Information message. This message contains UE information 
elements and CN information elements. The UE information elements include among others new SRNC 
identity and S-RNTI. The CN information elements contain among others Location Area Identification and 
Routeing Area Identification. The procedure shall be co-ordinated in all lu signalling connections existing for 
the MS. 

1 l)Upon receipt of the Relocation Detect message, the CN may switch the user plane from source RNC to target 
SRNC. If the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN sends Update PDP Context 
Request messages to the GGSNs concerned. The GGSNs update their PDP context fields and return an Update 
PDP Context Response. If the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN checks 
each individual MBMS service indicated by the MEMS contexts of the UE. If it is the first UE with this 
specific MBMS multicast service on this SGSN the SGSN requests the creation of an MBMS context on 
the GGSN and the establishment of a GTP tunnel between the SGSN and the GGSN. 

12) When the target SRNC receives the UTRAN Mobility Information Confirm message, i.e. the new SRNC — 

ID + S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC shall initiate the 
Relocation Complete pmcedurc by sending the Relocation Complete message to the-ncw-SGSN. The purpose 
of the Relocation Complete procedure is to indicate by the target SRNC the completion of the relocation of the 
SRNS to the CN. 

13) Upon receiving the Relocation Complete message or if it is an inter-SGSN SRNS relocation; the Forward 
Relocation Complete message, the old SGSN sends an lu Release Command message to the source RNC. 
When the RNC data- forwarding timer has expired the source RNC responds with an lu Release Complete. 

14) After the MS has fmished the RNTI reallocation procedure and if the new Routeing Area Identification is 
different from the old one, the MS initiates the Routeing Area Update procedure. Sec subclause "Location 
Management Procedures (lu mode only)". Note that it is only a subset of the RA update procedure that is 
perfoirned, since the MS is in PMM-CONNECTED mode. New TMGI(s) may be allocated to the UE for 
MBMS services. 
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Information Flows 



8.1 Service Discovery, initiation and Termination 
8.1.1 Service Announcement/Discovery 

MBMS service announcement/discovery mechanisms should allow users to request or he informed about the range of 
MBMS services available. This includes operator specific MBMS services as well as services from content providers 
outside of the PLMN. 

Operators/service providers may consider several service discovery mechanisms. This could include standard 
mechanisms such as SMS, or depending on the capability of the terminal, applications that encourage user 
interrogation. The method chosen to inform users about MBMS services may have to account for the users location, 
(e.g. current cell, in the HPLMN or VPLMN). Users who have not already subscribed to a MBMS service should also 
be able to discover MBMS services, .. .. 

The following could be considered useful for MBMS service discovery mechanisms (not exhaustive): - 

• SMS -CB 

• MBMS Broadcast mode to advertise MBMS Multicast Services 

• PUSH mechanism (WAP, SMS-PP) 

• Web URL 



8.2 Service Continuity and Mobility 

8.3 Interfaces to External Media Sources 

8.4 Roaming 

8.5 Security 

8.6 Charging 

9 Interaetion with CS/PS services 

10 Information Storage 
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Annex A 

This section contains text for information 

Decision process for selection of point-to-point or point-to-multipoint 
configuration 

For GSM, one way to achieve this would be for the paging messages which carry the TMGI to also specify the value 
to be included by the mobile into any subsequent (Packet) Channel Request message. After receiving a page with 
their TMGI, each mobile sends one (Packet) Channel Request message with the value specified in the page message. 
The BSS then counts the number of (Packet) Channel Request messages containing the specified contents received in 
each cell. This method seems likely to give an accurate measure of either (a) how many mobiles belonging to that 
group are in the cell (if there are less than, say, 10 mobiles in the cell), or (b) whether there are more than, say, 10 
"mobiles belonging to that jgroup in the cell. 

For UMTS: the method is FFS 
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